Den här uppgiften har vi strukturerat så att vi först har listat alla mål som angavs i uppgiftstexten, sedan har vi fyllt in frågorna som skall peka mot målet med fyllda punkter framför och till slut har mätdatat som skall ge svar på frågorna placerats under frågorna samt markerats med icke-fyllda punkter. I slutet har vi sammanställt alla mätdata som behövs i uppgiften och grupperat in dem för att göra det hela lite lättare att få en överblick av. Uppgifterna är numrerade enligt uppgiftstexten.
( Uppställning: )
Mål
· Frågor
o Mätdata
1) Produkten skall levereras i tid
· Hur lång tid tar det att leverera
o Tidsestimering o Personliga erfarenheter
· Hur mycket marginal har vi i tid?
o Tidsestimering o Enkät om hur stressigt projektet är bland gruppmedlemmarna
· Hur stor del av programmet som är färdigt?
o Andelen sprinter som är färdiga/ ännu ogjorda o Antalet funktioner som är färdiga / totala antalet funktioner o Projektchefens subjektiva bedömning
2) Produkten skall levereras med god kvalitet, med få buggar
· Hurudana processer har vi i projektet?
o Andel av tiden som utgörs av parprogrammering o Antalet parallella delprojekt som utförs samtidigt o Antal personer per delprojekt
· Hur pass regelbundet körs tester i programmeringen?
o Testintervall
· Hur mycket tid används till testning?
o Tidsuppföljning o Testtid/programmeringstid
· Hur arbetar man inom gruppen?
o Antal personer som arbetar o Antal testare mot antal programmerare o Antal testare som också är programmerare
· Hur bra är kvaliteten?
o Antal buggar för tillfället per 1000 rader kod o Antalet kritiska buggar i systemet o Antal fungerande funktioner
3) Koden bör vara väldokumenterad, bör underlätta underhåll
· Hur många arbetar med projektet?
o Antalet parallella delprojekt som utförs samtidigt o Antal personer per delprojekt o Subjektiv bedömning av programkodens dokumentation
· När sker dokumenteringen?
o Tidsuppföljning o Enkät bland programmerarna
· Hur mycket dokumentation behövs?
o Subjektiv uppskattning av programmet o Kravspecifikation o Designspecifikation
· Hur mycket dokumentation finns?
o Antal rader dokumentation i projektet o Antal rader dokumentation per del
· Hur relevant är dokumentationen?
o Subjektiv uppskattning av dokumentationen
4) Koden bör vara välskrivenså att underhåll förenklas
· Hurudana processer har man?
o Antal personer per grupp som arbetar med projektet o Antal parallella programmeringsgrupper
· Hur mycket dokumentation finns inne i koden?
o Antal kodrader dokumentation / programkod o Enkät bland programmerarna
· Hur standardiserad är programkoden?
o Subjektiv bedömning av projektchefen o Enkät bland programmerarna
· Hur enhetligt är programmet skrivet?
o Stickprov från olika funktioner och subjektiv bedömning
5) Effektiviteten för utvecklarna bör öka
· Hur effektiva är programmerarna?
o Antalet färdiga cykler /sprint o Antalet buggar /sprint
· Hur bra trivs programmerarna med sina arbeten?
o Enkät bland de anställda
· Hur bra är motivationen i projektgruppen?
o Enkät bland de anställda o Subjektiv uppskattning av projektchefen
6)
De flesta av våra mätdata i denna uppgift är interna mätdata, som mestadels kommer att vara ostandardiserade dokument för jämförelse inom projektgruppen. Det finns dock vissa dokument som kommer att användas som mätdata som kan anses vara externa mätdata och det är i den tredje uppgiften där vi tänkte använda oss av kravspecifikationen och designspecifikationen för att få reda på hur mycket dokumentation som behövs i projektet.
I frågan om produktdata eller processdata så använder vi oss av båda delarna, men försöker i mån av möjlighet använda oss av produktdata. Processdata är mer svårbestämt eftersom detaljerna kring arbetsmetoderna i projektet är odefinierade och det finns inte i samma utsträckning objektiva data klara data att utgå ifrån. Å andra sidan så kan också produktdata vara subjektiva ifall de anställda är medvetna om på vilket sätt kvaliteten på produkten mäts, så egentligen borde projektgruppen inte delges information om vilka mätdata som samlas in. Dock kan det leda till misstro i gruppen om det kommer fram att man granskar dem på ett sätt de inte vet om, så här har vi också en balansgång för att hitta en fungerande lösning.
7) Mätdata i hela kvalitetssäkringssystemet:
o Tidsestimering o Tidsuppföljning o Personliga erfarenheter av tidsestimeringen
o Andelen sprinter som är färdiga/ ännu ogjorda o Antalet funktioner som är färdiga / totala antalet funktioner o Antal fungerande funktioner o Antalet färdiga cykler /sprint o Antalet buggar /sprint o Antal buggar för tillfället per 1000 rader kod o Antalet kritiska buggar i systemet
o Antal rader dokumentation i projektet o Antal rader dokumentation per del o Antal kodrader dokumentation / programkod o Stickprov från olika funktioner och subjektiv bedömning av dokumentationen o Subjektiv bedömning av programkodens dokumentation
o Testintervall o Testtid/programmeringstid o Antal personer som arbetar på projektet o Antal testare mot antal programmerare o Antal testare som också är programmerare o Antal personer per delprojekt o Antal parallella programmeringsgrupper o Andel av tiden som utgörs av parprogrammering o Subjektiv bedömning av projektchefen
o Enkät bland programmerarna o Kravspecifikation o Designspecifikation
Som här synes har vi ett relativt stort antal olika mätdata, men de flesta av dem borde vara relativt enkla att samla in och analysera. Den troligen mest arbetskrävande delen, som även kräver alla gruppmedlemmars uppmärksamhet, kommer i det här fallet att vara den planerade enkäten. Den kommer att ta relativt mycket tid i anspråk början av projektet, men vartefter kommer medlemmarna att bli effektivare att svara på den och alla frågor behöver inte efter början ingå i enkäten varje gång. Dock borde man ändå regelbundet samla in tillräckligt med information för att kunna identifiera projektets läge och riktning. I slutet av projektet är det möjligt att en ännu mer omfattande enkät än den första enkäten vore på sin plats för att utvärdera projektet och samla in data för att stöda framtida förändringar av företagets processer och produkter.
En annan eventuellt problematisk sak är tidsuppföljningen, vilken kan vara krävande att implementera smidigt i ett litet projekt som TopBike. Oberoende av vilket verktyg som används för tidsuppföljning så kan man inte perfekt övervaka hur folk arbetar. Alltför noggrann tidsuppföljning kan också leda till att programmerarna i gruppen känner sig hotade och mister sin motivation att arbeta effektivt på grund av ”storebror ser dig”- känsla.
Buginsamling kan också vara problematisk, eftersom gruppmedlemmar relativt enkelt kan skapa missvisande data genom att låta bli att rapportera buggar, men å andra sidan kan man inte heller belöna uppsökning av buggar då detta kan leda till att programmerarna med vilje skapar buggar som de senare löser enkelt och på så vis förbättrar sina mätdata.
Också vårt förslag att mäta antalet rader dokumentation kan leda till att programmerare skriver onödigt långa och omständiga kommentarer i programmet, som då samtidigt innebär att den effektiva programmeringstiden minskar och tiden satt på kommentarer ökar, medan koden i värsta fall till och med kan bli svårare att förstå.
Kvalitetssäkring
Den här uppgiften har vi strukturerat så att vi först har listat alla mål som angavs i uppgiftstexten, sedan har vi fyllt in frågorna som skall peka mot målet med fyllda punkter framför och till slut har mätdatat som skall ge svar på frågorna placerats under frågorna samt markerats med icke-fyllda punkter. I slutet har vi sammanställt alla mätdata som behövs i uppgiften och grupperat in dem för att göra det hela lite lättare att få en överblick av. Uppgifterna är numrerade enligt uppgiftstexten.
( Uppställning: )
Mål
- · Frågor
o Mätdata1) Produkten skall levereras i tid
- · Hur lång tid tar det att leverera
o Tidsestimeringo Personliga erfarenheter
- · Hur mycket marginal har vi i tid?
o Tidsestimeringo Enkät om hur stressigt projektet är bland gruppmedlemmarna
- · Hur stor del av programmet som är färdigt?
o Andelen sprinter som är färdiga/ ännu ogjordao Antalet funktioner som är färdiga / totala antalet funktioner
o Projektchefens subjektiva bedömning
2) Produkten skall levereras med god kvalitet, med få buggar
- · Hurudana processer har vi i projektet?
o Andel av tiden som utgörs av parprogrammeringo Antalet parallella delprojekt som utförs samtidigt
o Antal personer per delprojekt
- · Hur pass regelbundet körs tester i programmeringen?
o Testintervall- · Hur mycket tid används till testning?
o Tidsuppföljningo Testtid/programmeringstid
- · Hur arbetar man inom gruppen?
o Antal personer som arbetaro Antal testare mot antal programmerare
o Antal testare som också är programmerare
- · Hur bra är kvaliteten?
o Antal buggar för tillfället per 1000 rader kodo Antalet kritiska buggar i systemet
o Antal fungerande funktioner
3) Koden bör vara väldokumenterad, bör underlätta underhåll
- · Hur många arbetar med projektet?
o Antalet parallella delprojekt som utförs samtidigto Antal personer per delprojekt
o Subjektiv bedömning av programkodens dokumentation
- · När sker dokumenteringen?
o Tidsuppföljningo Enkät bland programmerarna
- · Hur mycket dokumentation behövs?
o Subjektiv uppskattning av programmeto Kravspecifikation
o Designspecifikation
- · Hur mycket dokumentation finns?
o Antal rader dokumentation i projekteto Antal rader dokumentation per del
- · Hur relevant är dokumentationen?
o Subjektiv uppskattning av dokumentationen4) Koden bör vara välskrivenså att underhåll förenklas
- · Hurudana processer har man?
o Antal personer per grupp som arbetar med projekteto Antal parallella programmeringsgrupper
- · Hur mycket dokumentation finns inne i koden?
o Antal kodrader dokumentation / programkodo Enkät bland programmerarna
- · Hur standardiserad är programkoden?
o Subjektiv bedömning av projektchefeno Enkät bland programmerarna
- · Hur enhetligt är programmet skrivet?
o Stickprov från olika funktioner och subjektiv bedömning5) Effektiviteten för utvecklarna bör öka
- · Hur effektiva är programmerarna?
o Antalet färdiga cykler /sprinto Antalet buggar /sprint
- · Hur bra trivs programmerarna med sina arbeten?
o Enkät bland de anställda- · Hur bra är motivationen i projektgruppen?
o Enkät bland de anställdao Subjektiv uppskattning av projektchefen
6)
De flesta av våra mätdata i denna uppgift är interna mätdata, som mestadels kommer att vara ostandardiserade dokument för jämförelse inom projektgruppen. Det finns dock vissa dokument som kommer att användas som mätdata som kan anses vara externa mätdata och det är i den tredje uppgiften där vi tänkte använda oss av kravspecifikationen och designspecifikationen för att få reda på hur mycket dokumentation som behövs i projektet.
I frågan om produktdata eller processdata så använder vi oss av båda delarna, men försöker i mån av möjlighet använda oss av produktdata. Processdata är mer svårbestämt eftersom detaljerna kring arbetsmetoderna i projektet är odefinierade och det finns inte i samma utsträckning objektiva data klara data att utgå ifrån. Å andra sidan så kan också produktdata vara subjektiva ifall de anställda är medvetna om på vilket sätt kvaliteten på produkten mäts, så egentligen borde projektgruppen inte delges information om vilka mätdata som samlas in. Dock kan det leda till misstro i gruppen om det kommer fram att man granskar dem på ett sätt de inte vet om, så här har vi också en balansgång för att hitta en fungerande lösning.
7)
Mätdata i hela kvalitetssäkringssystemet:
o Tidsestimering
o Tidsuppföljning
o Personliga erfarenheter av tidsestimeringen
o Andelen sprinter som är färdiga/ ännu ogjorda
o Antalet funktioner som är färdiga / totala antalet funktioner
o Antal fungerande funktioner
o Antalet färdiga cykler /sprint
o Antalet buggar /sprint
o Antal buggar för tillfället per 1000 rader kod
o Antalet kritiska buggar i systemet
o Antal rader dokumentation i projektet
o Antal rader dokumentation per del
o Antal kodrader dokumentation / programkod
o Stickprov från olika funktioner och subjektiv bedömning av dokumentationen
o Subjektiv bedömning av programkodens dokumentation
o Testintervall
o Testtid/programmeringstid
o Antal personer som arbetar på projektet
o Antal testare mot antal programmerare
o Antal testare som också är programmerare
o Antal personer per delprojekt
o Antal parallella programmeringsgrupper
o Andel av tiden som utgörs av parprogrammering
o Subjektiv bedömning av projektchefen
o Enkät bland programmerarna
o Kravspecifikation
o Designspecifikation
Som här synes har vi ett relativt stort antal olika mätdata, men de flesta av dem borde vara relativt enkla att samla in och analysera. Den troligen mest arbetskrävande delen, som även kräver alla gruppmedlemmars uppmärksamhet, kommer i det här fallet att vara den planerade enkäten. Den kommer att ta relativt mycket tid i anspråk början av projektet, men vartefter kommer medlemmarna att bli effektivare att svara på den och alla frågor behöver inte efter början ingå i enkäten varje gång. Dock borde man ändå regelbundet samla in tillräckligt med information för att kunna identifiera projektets läge och riktning. I slutet av projektet är det möjligt att en ännu mer omfattande enkät än den första enkäten vore på sin plats för att utvärdera projektet och samla in data för att stöda framtida förändringar av företagets processer och produkter.
En annan eventuellt problematisk sak är tidsuppföljningen, vilken kan vara krävande att implementera smidigt i ett litet projekt som TopBike. Oberoende av vilket verktyg som används för tidsuppföljning så kan man inte perfekt övervaka hur folk arbetar. Alltför noggrann tidsuppföljning kan också leda till att programmerarna i gruppen känner sig hotade och mister sin motivation att arbeta effektivt på grund av ”storebror ser dig”- känsla.
Buginsamling kan också vara problematisk, eftersom gruppmedlemmar relativt enkelt kan skapa missvisande data genom att låta bli att rapportera buggar, men å andra sidan kan man inte heller belöna uppsökning av buggar då detta kan leda till att programmerarna med vilje skapar buggar som de senare löser enkelt och på så vis förbättrar sina mätdata.
Också vårt förslag att mäta antalet rader dokumentation kan leda till att programmerare skriver onödigt långa och omständiga kommentarer i programmet, som då samtidigt innebär att den effektiva programmeringstiden minskar och tiden satt på kommentarer ökar, medan koden i värsta fall till och med kan bli svårare att förstå.